Facilitating content accessibility via different communication formats

ABSTRACT

Methods and systems for facilitating content accessibility via different communication formats are provided. According to one embodiment, a method is provided for directing content requests to an appropriate content delivery network. A content request is received from a client. The content request relates to web page content published by a content publisher in an Internet Protocol version 4 (IPv4) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated to the other format by the content delivery network prior to receiving any content requests for the web page content. A communication format through which the client is capable of communicating is determined. The content request is directed to a content delivery network that supports the communication format through which the client is capable of communicating.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/452,682, filed Aug. 6, 2014, which is a continuation of U.S. patentapplication Ser. No. 13/194,826 filed on Jul. 29, 2011, which is herebyincorporated by reference in its entirety for all purposes.

COPYRIGHT NOTICE

Contained herein is material that is subject to copyright protection.The copyright owner has no objection to the facsimile reproduction ofthe patent disclosure by any person as it appears in the Patent andTrademark Office patent files or records, but otherwise reserves allrights to the copyright whatsoever. Copyright © 2011-2015, Fortinet,Inc.

BACKGROUND

1. Field

Embodiments of the present invention generally relate to facilitatingcontent accessibility via different communication formats. Inparticular, embodiments of the present invention relate to proactivelytranslating content originally received from an IPv4 enabled server inIPv4 format to an IPv6 format to facilitate accessibility via IPv6.

2. Description of the Related Art

Despite the commencement of a shift towards IPv6 (Internet Protocolversion 6), many Internet resources are still only accessible via IPv4(Internet Protocol version 4) due to the complexity and expense oftransitioning to IPv6.

SUMMARY

Methods and systems are described for facilitating content accessibilityvia different communication formats. According to one embodiment, amethod is provided for directing content requests to an appropriatecontent delivery network. A content request is received from a client.The content request relates to web page content published by a contentpublisher in an Internet Protocol version 4 (IPv4) format or an InternetProtocol version 6 (IPv6) format that is obtained by the contentdelivery network from the content publisher and is translated to theother format by the content delivery network prior to receiving anycontent requests for the web page content. A communication formatthrough which the client is capable of communicating is determined. Thecontent request is directed to a content delivery network that supportsthe communication format through which the client is capable ofcommunicating.

Other features of embodiments of the present invention will be apparentfrom the accompanying drawings and from the detailed description thatfollows.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of example,and not by way of limitation, in the figures of the accompanyingdrawings and in which like reference numerals refer to similar elementsand in which:

FIG. 1 is a block diagram illustrating an example of native IPv6 trafficcommunications between an IPv6 enabled client and server.

FIG. 2 is a block diagram illustrating an example of IPv6 communicationsvia an IPv6 tunnel over an IPv4 backbone.

FIG. 3 is a block diagram illustrating an embodiment of a networkenvironment in which clients are intelligently directed to serverscapable of servicing client requests.

FIG. 4 is a flow chart illustrating an embodiment of a process fordirecting a client.

FIG. 5 is a block diagram illustrating an embodiment of a networkenvironment in which a proxy server is employed to translate contentfrom a first format into a second format.

FIG. 6 is a flow chart illustrating an embodiment of a process fortranslating IPv4 content into IPv6 content.

DETAILED DESCRIPTION

Methods and systems are described for facilitating content accessibilityvia different communication formats. Embodiments of the presentinvention can be implemented in numerous ways, including as a process;an apparatus; a system; a composition of matter; a computer programproduct embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims,and the invention encompasses numerous alternatives, modifications, andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example, andthe invention may be practiced according to the claims without some orall of these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

As the long-anticipated address exhaustion of IPv4 (Internet Protocolversion 4) becomes imminent, mechanisms to transition to IPv6 (InternetProtocol version 6) have become increasingly prevalent. Although manynetworking devices are now dual stack and support both IPv4 and IPv6,most existing ISP (Internet Service Provider) networks still onlysupport native IPv4 connectivity. As a result, a very small percentageof existing Internet traffic comprises solely native IPv6 traffic.Rather, a significant portion of existing IPv6 traffic employs atunneling mechanism to carry IPv6 traffic over an IPv4 network.

FIG. 1 is a block diagram illustrating an example of native IPv6 trafficcommunications between an IPv6 enabled client and server. As depicted, arequest from IPv6 enabled client 102 is received by IPv6 enabled server104 via IPv6 network 106, and a response to the request from IPv6enabled server 104 is received by IPv6 enabled client 102 via IPv6network 106. The communications between client 102 and server 104 arefacilitated by one or more ISPs that are natively connected to IPv6backbone 106. Although described as IPv6 enabled, client 102 and server104 may also be enabled to communicate via one or more other protocolstacks such as IPv4. Similar communications as those described withrespect to FIG. 1 occur with respect to native communications usingother protocol stacks such as IPv4.

In contrast, FIG. 2 is a block diagram illustrating an example of IPv6communications via an IPv6 tunnel over an IPv4 backbone. Tunnelingeffectively facilitates encapsulation of IPv6 packets within IPv4 sothat existing IPv4 infrastructure may be employed to carry IPv6 packetsto reach an IPv6 network. In the given example, dual stack client 202 isIPv6 capable but limited, for example, by an associated ISP, to IPv4network connectivity. Client 202 employs a tunnel broker service thatenables connectivity to IPv6 network 204 via a tunnel 206 over IPv4network 208. Specifically, a request to an IPv6 destination from client202 is tunneled 206 over IPv4 network 208 to a dual stack router 210 ofthe tunnel broker service, which provides connectivity to IPv6 network204 and which directs the request from client 202 via IPv6 network 204to IPv6 server 212. A response to the request from IPv6 server 212 isreceived via IPv6 network 204 by dual stack router 210 and directed viatunneling 206 over IPv4 network 208 to client 202.

In many cases, IPv6 tunneling over an IPv4 network introducesperformance degradations, for example, due to the latency inherent inthe extra transmissions as well as performance limitations imposed bytunnel broker service gateways (e.g., router 210 of FIG. 2) thatfacilitate communications with an IPv6 network. Due to the poorperformance typically resulting from such tunneling techniques, IPv6 hasyet to receive more widespread deployment. Despite the performancelimitations, many Internet resources (e.g., websites) have neverthelessbecome IPv6 enabled, for example, due in part to a desire to be at theforefront of migration to IPv6. As a result, many domain names areaccessible via both IPv4 and IPv6 addresses. In DNS (Domain NameSystem), domain names are mapped to an IPv4 address using an A recordand to an IPv6 address using an AAAA (quad A) record. In some cases,default and/or user configurations of client hardware and/or softwarehave resulted in domain names being automatically resolved into IPv6addresses, if available, regardless of whether native IPv6 networkconnectivity exists at the client. Such indiscriminate use of IPv6 hasin many cases detrimentally impacted end user experience, especially forclients that are not natively connected to an IPv6 network.

Techniques for more intelligently routing or directing traffic based onexpected performance are disclosed herein. Although dual stack devicescapable of communicating using IPv4 and/or IPv6 are described in some ofthe given examples, the techniques disclosed herein may be employed withrespect to any device capable of communicating using any one or moreprotocol stacks or communication formats.

FIG. 3 is a block diagram illustrating an embodiment of a networkenvironment in which clients are intelligently directed to serverscapable of servicing client requests. The various components comprisingnetwork environment 300 communicate via one or more private and/orpublic networks using any appropriate communication protocols andcomprise devices that are capable of communicating using any one or morecommunication formats. For instance, one or more of components 302-306may comprise dual stack devices that are enabled for both the IPv4 andIPv6 protocol stacks. Such a dual stack device may be configured, forexample, to automatically communicate via IPv4 or IPv6 depending onwhether the IP address of a destination device comprises an IPv4 or IPv6address. Although components may be depicted as single blocks in theaccompanying figures, in various embodiments, a block may comprise anynumber of interconnected physical and/or logical components. Forinstance, in some embodiments, traffic manager 302 comprises a pluralityof networked devices located in different geographical regions.

Traffic in network environment 300 is managed by traffic manager 302. Insome embodiments, traffic manager 302 comprises a redirection node orhost configured to direct a client 304 to an appropriate server 306capable of servicing a client request. Traffic manager 302 may beemployed by a publisher to manage client requests for content publishedby the publisher. In such cases, client requests for content publishedby the publisher may be directed or redirected to traffic manager 302,for example, via a CNAME (Canonical Name) record of DNS. Traffic manager302, in turn, redirects clients 304 to appropriate servers 306 toservice client requests. For example, traffic manager 302 may redirect aclient in a manner that strives to optimize performance in servicing theclient request and/or according to a traffic management policy specifiedby an associated publisher whose content is being requested. In someembodiments, traffic manager 302 is natively connected to a plurality ofnetworks and/or capable of communicating via a plurality ofcommunication formats such as IPv4 and IPv6. Although described as acentralized, web-based service with respect to the example of FIG. 3,the functionality described herein as being performed by traffic manager302 may in other embodiments be implemented as a host-based solution,for example, on servers 306.

Server 306(a) and server 306(b) are configured to serve content. Forexample, server 306(a) and server 306(b) may be configured to servecontent published by a publisher. In such cases, servers 306(a) and306(b) may belong to the publisher (e.g., the servers may comprisepublisher origin servers), a content delivery network (CDN) contractedby the publisher, or another third party entity employed to servecontent on behalf of the publisher. Each of servers 306(a) and 306(b) isconfigured to communicate via a prescribed communication format. In thegiven example, server 306(a) is configured to communicate via IPv4 whileserver 306(b) is configured to communicate via IPv6. Although depictedin FIG. 3 as separate blocks or devices, in other embodiments, servers306(a) and 306(b) may comprise a single device, such as a dual stackdevice configured to communicate natively with both IPv4 and IPv6networks.

In some embodiments, traffic manager 302 takes into consideration thecommunication format that gives a client the best expected performancewhen making a redirection decision. In some cases, for example, betterperformance may be expected by redirecting a client to a serverconnected to a network to which the client is natively connected. Forinstance, better performance may be expected by redirecting a nativeIPv4 client 304(a) to a native IPv4 server 306(a) and similarly a nativeIPv6 client 304(b) to a native IPv6 server 306(b) to avoid theperformance degradations inherent in tunneling communications overotherwise incompatible networks. In some embodiments, traffic manager302 is configured to determine whether a communication received from aclient has been tunneled using a tunneling service. A tunneledcommunication may be identified, for example, by comparing a source IPaddress of the communication with a list or database of known IPaddresses associated with tunneling services. In some embodiments, aclient identified by traffic manager 302 to be using a tunneling servicemay be redirected by traffic manager 302 to a server connected to anetwork to which the client has native connectivity so that furthertunneling can be avoided.

As an example, consider a dual stack client 304(a) natively connected toonly an IPv4 network but configured to communicate via IPv6 whenever anIPv6 destination is available, e.g., whenever a destination domain nameis resolvable into an IPv6 address. In this example, client 304(a)connects to an IPv6 destination using a tunneling service that directsIPv6 communications to and from client 304(a) via an IPv6 tunnel over anIPv4 network and via a dual stack router of the tunneling service thatis natively connected to both IPv4 and IPv6 networks as described abovewith respect to FIG. 2. An IPv6 communication from client 304(a) isreceived by traffic manager 302 via a native IPv6 network. The sourceIPv6 address of such a communication from the client, however, comprisesthe IPv6 address of the tunneling service router. By comparing thesource IP address of a received communication from client 304(a) againsta list of known IP addresses of tunneling service routers, trafficmanager 302 is able to deduce the use of a tunneling service and thatclient 304(a) does not have native connectivity to an IPv6 network. Ifthe performance of tunneled communications is expected to be inferior tocommunications over a native network, traffic manager 302 may choose toredirect client 304(a) to IPv4 server 306(a) so that further tunnelingcan be avoided. In some such cases, a redirect response from trafficmanager 302 to client 304(a) may be tunneled, but subsequent request andresponse communications between client 304(a) and server 306(a) occurover a native network of both devices. A similar decision by trafficmanager 302 to prevent further tunneling may arise in the inversescenario. For example, a client 304(b) natively connected to only anIPv6 network and communicating with IPv4 using a tunneling service thatdirects IPv4 communications to and from client 304(b) via an IPv4 tunnelover an IPv6 network and via a dual stack router of the tunnelingservice that is natively connected to both IPv6 and IPv4 networks may beredirected by traffic manager 302 to IPv6 server 306(b) so thattunneling can be avoided during client-server communications.

In some embodiments, a determination by traffic manager 302 of themanner in which to redirect a client 304 is generally based onoptimizing expected performance. Although in some cases avoidingtunneling may be expected to optimize performance, tunneling may offerimproved performance in some scenarios. For example, tunneling may beexpected to provide improved performance when a native network isexperiencing outages or is congested, or, for instance, if the nodesinvolved in tunneled communications are all geographically located incloser proximity than the nodes involved in corresponding nativecommunications. Thus, if tunneled communications are expected to resultin improved performance, traffic manager 302 may redirect a client to aserver that entails tunneled communications between the two devices. Forexample, IPv4 client 304(a) may be redirected by traffic manager 302 toIPv6 server 306(b) and likewise an IPv6 client 304(b) may be redirectedby traffic manager 302 to IPv4 server 306(a).

In various embodiments, traffic manager 302 may facilitate and/ormediate client-server communications with respect to any communicationprotocols such as HTTP (Hypertext Transfer Protocol), SSL (SecureSockets Layer), FTP (File Transfer Protocol), RTMP (Real Time MessagingProtocol), RTMP-E (Encrypted Real Time Messaging Protocol), RTMP overHTTP, torrent style protocols, DNS protocols, etc. In some embodiments,traffic manager 302 is at least in part configured with DNSfunctionality. For example, traffic manager 302 may be employed toresolve or aid in resolving DNS requests from clients 304. In some suchcases, an expected optimal protocol stack for communication may beselected by traffic manager 302 for a client 304 at the DNS level, andtraffic manager 302 may accordingly respond to a DNS request from aclient 304 with an appropriate DNS response such as an A record or anAAAA record for IPv4 and IPv6, respectively.

Most existing network devices are dual stack and capable ofcommunicating via both IPv4 and IPv6. However, all devices may not bedual stack in the future once migration to IPv6 is complete. In suchcases, any appropriate techniques to determine whether a device is dualstack may be employed. Such techniques may generally be employed todetermine whether a device supports any one or more communicationformats. In some embodiments, test content accessible only via aprescribed communication format is embedded in a resource such as a webpage accessed by a client to determine whether the client is capable ofaccessing the test content and thus to deduce whether the client iscapable of communicating using the prescribed communication format. Forexample, IPv4 and/or IPv6 test content may be embedded into a web pageaccessed by a client to determine whether the client is capable ofcommunicating via IPv4, IPv6, or both. The results of such tests may bestored in one or more browser cookies at the client so that the tests donot have to be repeatedly performed for the same client at least untilthe cookies expire. A client is intelligently redirected to anappropriate server based on the communication format or protocol stackvia which it is capable of most efficiently communicating.

In some embodiments, various types of information may be learned and/orstored by traffic manager 302. For example, lists of known or determinednative IP (e.g., IPv4 and IPv6) addresses may be maintained indatabases. Such databases of native IP addresses may be employed, forexample, when determining whether client communications comprise nativeor tunneled communications. In some cases, client information such as IPaddresses and compatible protocol stacks may be learned and stored forfuture use so that such information does not have to be repeatedlydetermined for a particular client and may only periodically bere-checked for changes. In various embodiments, any other appropriatemetrics may be tracked and later used for making more dynamic andgranular redirection decisions.

FIG. 4 is a flow chart illustrating an embodiment of a process fordirecting a client. In some embodiments, process 400 is employed by atraffic manager, such as traffic manager 302 of FIG. 3. Process 400starts at step 402 at which a request is received from a client. Invarious embodiments, the request received at step 402 may comprise arequest for any appropriate resource such as a content request or a DNSrequest and may be communicated via any appropriate communicationprotocol. At step 404, a set of one or more supported communicationformats via which the client is capable of communicating are determined.For instance, step 404 may include various techniques for determiningwhether the client is IPv4 enabled, IPv6 enabled, or dual stack. In someembodiments, step 404 includes determining whether the source IP addressof the received request is part of a list of IP addresses associatedwith tunneling services and/or a list of known native IP addresses. Insome such cases, if the source IP address is found to be associated witha tunneling service, it is deduced that the client is dual stack. Insome embodiments, step 404 includes determining the ability of theclient to access a set of test content each of which is accessible via aprescribed communication format as described above. At step 406, acommunication format that is expected to give the client the bestperformance is selected from the set of supported communication formatsdetermined at step 404. For example, a communication format that allowsthe client to communicate via a network to which it is nativelyconnected may be selected at step 406 if communication via a nativenetwork is expected to provide better performance. Alternatively, acommunication format that requires a client to communicate via tunnelingmay be selected at step 406 if communication via a native network isexpected to provide inferior performance. At step 408, the client isdirected or redirected to a node capable of servicing the client requestvia the communication format selected at step 406.

As a result of process 400, for example, a native IPv4 client (includinga native IPv4 client communicating via IPv6 tunneling) may be redirectedto a native IPv4 server, and a native IPv6 client (including a nativeIPv6 client communicating via IPv4 tunneling) may be redirected to anative IPv6 server. Alternatively, if tunneling is expected to providebetter performance than communications over a native network, a clientmay be redirected using process 400 to a server that entails tunneledcommunications between the devices. For example, a native IPv4 client(including a native IPv4 client already communicating via IPv6tunneling) may be redirected to a native IPv6 server, and a native IPv6client (including a native IPv6 client already communicating via IPv4tunneling) may be redirected to a native IPv4 server. In general,process 400 may be employed to select and direct a client via one of aplurality of possible network routes that is expected to give optimalperformance.

Numerous existing Internet resources such as web servers are only IPv4enabled. It may be desirable for such resources to be IPv6 enabled aswell. For example, a server associated with a publisher may only becapable of natively communicating via an IPv4 network, but the publishermay desire that its content also be natively accessible via IPv6. Insome embodiments, a proxy server that translates content defined in afirst format into a second format is employed to make a resourcenatively accessible in the second format. For example, a proxy servernatively connected to both IPv4 and IPv6 networks may be employed toproxy content from an IPv4 server over an IPv4 network, translate thecontent into IPv6, and natively serve the IPv6 content to IPv6 usersover an IPv6 network.

FIG. 5 is a block diagram illustrating an embodiment of a networkenvironment in which a proxy server is employed to translate contentfrom a first format into a second format. For example, networkenvironment 500 may be employed to make the content of an IPv4accessible website also accessible via IPv6. IPv4 server 502 isconnected to and configured to serve content published by a publishervia an IPv4 network. In various embodiments, server 502 may belong tothe publisher (e.g., the server may comprise a publisher origin server),a content delivery network contracted by the publisher, or another thirdparty entity employed to serve content on behalf of the publisher. IPv4server 502 responds to an IPv4 request from client 504(a) with anappropriate IPv4 response. In the given example, IPv6 proxy server 506comprises a dual stack device that is connected to and configured tonatively communicate via both IPv4 and IPv6 networks. In variousembodiments, proxy server 506 may belong to the publisher or a thirdparty contracted by the publisher. On its backend, proxy server 506 isconfigured to proxy content from IPv4 server 502 via an IPv4 network.Proxy server 506 may seed content from server 502 to facilitate siteand/or cache acceleration. Proxy server 506 in some cases includesappropriate buffers for translating IPv4 packets obtained from server502 into IPv6 packets. On its frontend, proxy server 506 is connected toand configured to serve IPv6 content natively via an IPv6 network. IPv6proxy server 506 responds to an IPv6 request from a client 504(b) withan appropriate IPv6 response. In various embodiments, a client 504 maybe redirected to IPv4 server 502 or IPv6 proxy server 506 by a trafficmanager such as traffic manager 302 of FIG. 3. Proxy server 506 may insome embodiments also be configured to receive client requests for andserve IPv4 content. In some embodiments, a special server may beinterposed between server 502 and proxy server 506 that obtains datafrom server 502 using a protocol (e.g., UDP (User Datagram Protocol))that is more amenable to packet fragmentation and that provides data toproxy server 506 in a format that facilitates accelerated packettranslation at proxy server 506. Although the example provided withrespect to FIG. 5 describes IPv4 to IPv6 translation, proxy server 506may similarly be employed to translate between any other formats. Forinstance, proxy server 506 may similarly be employed for IPv6 to IPv4translation.

FIG. 6 is a flow chart illustrating an embodiment of a process fortranslating IPv4 content into IPv6 content. Although IPv4 to IPv6translation is described, process 600 may be similarly employed totranslate content between any formats. In some embodiments, process 600is employed by proxy server 506 of FIG. 5. Process 600 starts at step602 at which IPv4 content is received from an IPv4 server. Such IPv4content may be received, for example, via an IPv4 network. In someembodiments, step 602 includes appropriately buffering the received IPv4content. At step 604, the IPv4 content received at step 602 istranslated into IPv6. The resulting IPv6 content may be employed toservice client requests over an IPv6 network. In various embodiments,IPv4 content may be obtained and translated into IPv6 content usingprocess 600 prior to receiving any client requests for the content or inresponse to a client request for the content. In some embodiments, theIPv4 content received at step 602 may be employed to service clientrequests over an IPv4 network. Process 600 may be used, for example, tomake IPv4 content also available via IPv6.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. A system, comprising: a processor configured to:send a test content to a client to determine a communication format viawhich the client is capable of communication; determine a communicationformat via which the client is capable of communication based on aresponse to the test content; receive a content request from a client;and direct the request to a content delivery network that supports thecommunication format via which the client is capable of communication;wherein the requested content comprises web page content published by acontent publisher in one of Internet Protocol version 4 (IPv4) formatand Internet Protocol version 6 (IPv6) format and obtained by thecontent delivery network from the content publisher and translated intoIPv6 format or IPv4 format, respectively, by the content deliverynetwork prior to receiving the content request based on the response tothe test content; and a memory coupled to the processor and configuredto provide the processor with instructions.
 2. The system of claim 1,wherein the processor is dual stack.
 3. The system of claim 1, whereinthe processor is natively connected to both an IPv4 network and an IPv6network.
 4. The system of claim 1, wherein the processor is configuredto communicate with an IPv4 enabled server natively via an IPv4 network.5. The system of claim 1, wherein the processor is configured tocommunicate with an IPv6 enabled client natively via an IPv6 network. 6.The system of claim 1, wherein the processor is configured to direct thecontent request based on estimated performance of the content deliverynetwork in connection with servicing the content request.
 7. The systemof claim 1, wherein the processor is configured to direct the contentrequest based on a traffic management policy specified by the contentpublisher.
 8. A method, comprising: sending a test content to a clientto determine a communication format via which the client is capable ofcommunication; determining a communication format via which the clientis capable of communication based on a response to the test content;receiving a content request from a client at a processor; directing therequest to a content delivery network that supports the communicationformat via which the client is capable of communication; and wherein therequested content comprises web page content published by a contentpublisher in one of Internet Protocol version 4 (IPv4) format andInternet Protocol version 6 (IPv6) format and obtained by the contentdelivery network from the content publisher and translated into IPv6format or IPv4 format, respectively, by the content delivery networkprior to receiving the content request based on the response to the testcontent.
 9. The method of claim 8, wherein the processor is dual stack.10. The method of claim 8, wherein the processor is natively connectedto both an IPv4 network and an IPv6 network.
 11. The method of claim 8,wherein the processor is configured to communicate with an IPv4 enabledserver natively via an IPv4 network.
 12. The method of claim 8, whereinthe processor is configured to communicate with an IPv6 enabled clientnatively via an IPv6 network.
 13. The method of claim 8, wherein theprocessor is configured to direct the content request based on estimatedperformance of the content delivery network in connection with servicingthe content request.
 14. The method of claim 8, wherein the processor isconfigured to direct the content request based on a traffic managementpolicy specified by the content publisher.
 15. A computer programproduct embodied in a non-transitory computer readable storage mediumand comprising computer instructions for: sending a test content to aclient to determine a communication format via which the client iscapable of communication; determining a communication format via whichthe client is capable of communication based on a response to the testcontent; receiving a content request from a client at a processor; anddirecting the request to a content delivery network that supports thecommunication format via which the client is capable of communication;wherein the requested content comprises web page content published by acontent publisher in one of Internet Protocol version 4 (IPv4) formatand Internet Protocol version 6 (IPv6) format and obtained by thecontent delivery network from the content publisher and translated intoIPv6 format or IPv4 format, respectively, by the content deliverynetwork prior to receiving the content request based on the response tothe test content.
 16. The computer program product of claim 15, whereinthe computer program product is configured to communicate via both anIPv4 network and an IPv6 network.
 17. The computer program product asrecited in claim 16, further comprising computer instructions forreceiving a content request from an IPv4 enabled client and providingthe requested content to the IPv4 enabled client in IPv4 format.